This line shouldn't be necessary.

I see that most of the tasks on this module have the @set_code_owner_attribute decorator, which is not compatible with the @shared_task decorator when using UserTask, that's why I'm manually setting it here, as it's done also on the existing course export/import tasks.

Although I'm not sure I understand 100% why it's needed there, are you sure this is not needed here?

Setting the code owner is something we did at edX so that if the APM error monitoring started throwing a bunch of errors on the endpoint, the person on call would know who to contact to help triage the issue. It also makes it easier for teams to build dashboards around it. I guess there's no harm in keeping it, but I don't think anyone will be looking at the data that it generates.

@robrap, @feanil: Am I remembering that correctly?

Thanks. This decorator is no longer needed. See:

• [DEPR]: Code Owner Monitoring edx-django-utils#469

Thanks!, I'll remove it

After removing set_code_owner_attribute_from_module, the "Semgrep code quality" check is now failing with:

test_root.semgrep.celery-missing-code-owner-function
Celery tasks need to be decorated with
@set_code_owner_attribute (from the
edx_django_utils.monitoring module) in order for us to
correctly track code-owners for errors and in other
monitoring.

      For more information, see the Celery section of "Add     
      Code_Owner Custom Attributes to an IDA" in the Monitoring
      How-Tos of <https://docs.openedx.org/projects/edx-django-
      utils/en/latest/>.

It seems there is a test specific for this still up

Apologies. You can restore it, or remove the test. It’s a DEPR that requires attention at some point.

thanks, restored it for now.

Will this generated file have a difficult-to-guess URL (e.g. a randomized value for the directory prefix to the file)? My understanding is that UserTaskArtifacts are not secured via auth by default, and that we have to rely on making difficult-to-brute-force URLs.

For the default filesystem store, this is correct, it's not secured by default, however other stores may implement security themselves, for example, the S3 store does have this and generates a temporary signed url for the file.

In my tests, the files generates using the filesystem storage look like "/media/user_tasks/2025/10/03/lib-wgu-csprob-2025-10-03-153633.zip", the only thing that would make them kind of difficult to guess are the datetime in the file name.

I could add a random postfix to the filename, I'm not sure if I can control the directory as it's managed by the UserTasks library.

If the S3 version has a temp signed url for the file, I think that's acceptable. This is one of the things we'll want to include in the release notes.

Here is more info on how this behaves, from the django-user-tasks docs: https://django-user-tasks.readthedocs.io/en/latest/authorization.html#artifact-url-access

So at a low level, I think we'd want to filter by task_class (so there's no mixing of backup and restore tasks), and put a bound on created (automated processes may make many, many tasks over time).

But at a higher level, is this part of the API here to service the use case where someone wanders away from the backup page and then comes back to it? Because if so, I'd rather we just not handle that case yet, and require the user to stay on the page. It shouldn't take that long to create the backup, and it's not clear to me how long a backup should remain "good", or what exactly the logic for invalidating a backup download should be, if we allow people to access historical backups.

ok, I removed that use case, now we always need to specify the task_id. thanks!

Since task_id is now required, we don't need all this any longer. We can do something more like:

@rodmgwgu CC @holaontiveros Do you think we can update this to return an absolute URL, before Ulmo? REST APIs should generally only return absolute URLs, doubly so if the field is called "url", and triply so if we're talking about file storage which may be on a totally separate server/domain like S3. But this API is currently returning just the path part.

I noticed this here in the corresponding frontend PR.

@bradenmacdonald I modeled this one around the existing course export code here, which is doing the same, it seems that if it's S3, it will give us an absolute url, but for filestorage it returns a relative path.

But what you mention makes sense, I'll review this to always return an absoulte URL.

@bradenmacdonald here is the PR addressing this issue: #37508